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1.0 INTRODUCTION 


1.1 Identification of Volume 

This is the Management Control and Status Reports Documentation 
Standard and Data Item Descriptions Volume rolled-out from the 
Information System Life-Cycle and Documentation Standards. 


1.2 Scope of Volume 

A management control and status reports document contains all 
reports generated during the course of acquiring, developing, 
assuring, and maintaining an information system or a hardware, 
software, or operational procedures component. This volume 
states the SMAP documentation standard for a management control 
and status reports document applicable to all NASA information 
systems and software, hardware, and operational procedures 
components and related processes. 

The selection, adaptation, and enforcement of these documentation 
standards is the responsibility of the cognizant program/project 
manager. 

IT IS ASSUMED WITHIN THIS VOLUME THAT THE READER OF THIS STANDARD 
IS FAMILIAR WITH THE TERMS AND CONTENTS OF THE PARENT VOLUME 
CONCERNING INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION 
STANDARDS . 


1.3 Purpose and Objectives of Volume 

The purpose of this volume is to provide a well organized, easily 
used standard for management control and status reports used in 
monitoring and controlling the management, development, and 
assurance of information systems and software, hardware, and 
operational procedures components and related processes. 


1.4 Volume Status and Schedule 

Release 4.2C was the first complete release for Version 4 of the 
Information System Life-Cycle and Documentation Standards 
document . All five volumes of the document underwent a SMAP and 
agency review. Release 4.3 is an update to Release 4.2C based on 
the approved RIDs from this review. The RID review board 
determined that change bars will not be used to show the 
differences between Releases 4.2C and 4.3, as 4.3 is the first 
baselined release of the Version 4 standards. 
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1.5 Volume Organization and Roll-Out 

Sections 1 and 2 of this volume identify it, describe its 
purpose, and cite other related documents. Section 3 provides 
the rationale and scope for this documentation standard. Section 
4 presents the actual standard and related rules for 
documentation, and illustrates the roll-out concept. Section 5 
offers guidelines for applying the standard to the needs of a 
particular application and organizational environment. Section 6 
proposes means for assuring and enforcing the standard. 

The Data Item Description (DID) for a management control and 
status reports document is contained in Section 7, together with 
specification of the minimum content for a selection of reports. 

Section 8 defines abbreviations and acronyms; Section 9 contains 
a glossary of significant terms used throughout the standards. 
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2 . 0 RELATED DOCUMENTATION 


2 . 1 Parent Documents 

The following document is the parent of this volume: 

1) Information System Life-Cycle and Documentation Standards, 
Release 4.3, 2/28/89. Washington: NASA Office of Safety, 

Reliability, Maintainability, and Quality Assurance. 


2.2 Applicable Documents 

The following volumes/documents are referenced herein and are 

directly applicable to this document: 

1) Management Plan Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

2) Product Specification Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

3) Assurance Specification Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

4) IEEE Standard Glossary of Software Engineering Terminology. 

ANSI/IEEE Std 729-1983. New York: Institute of Electrical 

and Electronic Engineers, Inc. 


2 . 3 Information Documents 

The following documents, although not directly applicable, are 
referenced for historical continuity: 

1) Military Standard for Defense System Software Development, 
DoD-STD— 2 167 , 4 June 1985, and DoD-STD-2167A, 27 October 1987. 

2) NASA Software Data Item Descriptions, Version 3, November 

1986. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. (Additional Data 
Item Descriptions were published as Versions 3.1 — 3.5 m 
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1987.) 

3) Space Station Program Software Management Policies, 
1986. 


November 


4 


Release 4.3, 2/28/89 



MANAGEMENT CONTROL AND STATUS REPORTS DOCUMENTATION STANDARD 


3.0 OVERVIEW OF THE MANAGEMENT CONTROL AND STATUS REPORTS 
DOCUMENTATION STANDARD 


3 . 1 Scope of Standard 

The SMAP Management Control and Status Reports Documentation 
Standard is applicable to all NASA information systems and their 
software, hardware, and operational procedures components. 

The selection, adaptation, and enforcement of these documentation 
standards is the responsibility of the cognizant program/project 
manager. 

It is important to note that these documentation standards are 
not management, technical and engineering, or assurance 
standards. However, the life-cycle and documentation standards 
provide the mechanism to document the selected activities and 
related specifications supporting any management, technical and 
engineering, or assurance standards. 


3.2 Rationale for Standard 

The rationale for the documentation structure presented in this 
standard is to provide visibility and to allow management to 
assign responsibility for the generation of such documentation. 

As specified by the Information System Life-Cycle and 
Documentation Standards, the documentation set for each 
information system and component consists of: 

1) a management plan 

2) a product specification 

3) an assurance specification 

4) a management control and status reports document 

An assumption upon which the SMAP documentation standard is based 
is that it is the responsibility of program/project management to 
decide what information is to be formally recorded. The 
documentation standard merely indicates the organization for such 
information. 

The function of the management control and status reports 
documentation standard is to provide a common, uniform, and 
effective method for cataloging and retrieving all management 
control and status reports specified in the management plan, and 
to provide the minimum content for typical reports specified in 
the management plan. 
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3.3 Interface With Other Standards 

This documentation standard is derived from the NASA Version 3 
software standards maintained by NASA Headquarters Code Q, Office 
of Safety, Reliability, Maintainability and Quality Assurance. 

This documentation standards volume is one of four that augment 
and detail the life-cycle standards for information systems 
specified in the parent document. The other three documentation 
standards volumes are referenced in Section 2.2. 
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4.0 THE MANAGEMENT CONTROL AND STATUS REPORTS DOCUMENTATION 
STANDARD 

The management control and status reports documentation standard 
describes the organization of and minimum content _ for reports at 
a single node in an information system's decomposition tree. 

(For more information on system decomposition, refer to the 
Information System Life-Cycle and Documentation Standards.) 


4.1 Management Control and Status Reports Document Structure 

The purpose of the Management Control and Status Reports document 
is to organize all the reports and relate individual reports to 
each other, to the management plan, and to the documents that 
they affect. The Management Control and Status Reports document 
may contain the actual reports or may contain pointers (or index 
information) to the reports. The content of the Management 
Control and Status Reports document is determined by the reports 
designated in the management plan and it functions as a catalog 
or index to the various sets of reports for the information 
system or component. 

The top-level structure of the Management Control and Status 
Reports document mirrors that of the associated management plan, 
i.e., the reports are first categorized by the organization 
(acquirer, development provider, sustaining engineering and 
operations provider) responsible for the report type. For each 
organization, the reports are categorized into three major 
classifications: management, engineering, and assurance. These 

classifications identify the documentation set volume the report 
affects or is associated with. The specific reports within each 
organization and classification are designated in the management 
plan. The structure is given in Figure 4-1. 


4.2 Responsibility for the Preparation of the Management Control 
and Status Reports Document 

Every management plan reflects an agreement between the acquirer 
and the providers (such as the developer). The acquirer's 
reporting plans are specified in the acquisition plan section of 
the management plan along with any reporting requirements for the 
providers. Similarly, the provider(s) ' reporting plans are 
specified in the appropriate sections of the management plan. 

The actual selection and specification of the reports to be used 
during the management, engineering, and assurance of an 
information system or component is performed during planning and 
is documented in the management plan. (The actual report format 
and distribution are usually based on report standards and 
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ACQUIRER'S REPORTS 

Management Reports 
Engineering Reports 
Assurance Reports 

DEVELOPMENT PROVIDER'S REPORTS 
Management Reports 
Engineering Reports 
Assurance Reports 

SUSTAINING ENGINEERING AND OPERATIONS 

PROVIDER'S REPORTS 

Management Reports 
Engineering Reports 
Assurance Reports 


Figure 4-1. Structure for Management Control and Status Reports. 


procedures in the standards and procedures repository for a 
specific application or organization.) 

The acquirer is responsible for the overall Management Control 
and Status Reports document as well the acquirer's reports. 
Providers are responsible for keeping current their respective 
sections of the Management Control and Status Report document. 

Each Management Control and Status Reports document is prepared 
for a particular information system or component; i.e., for a 
node in the system decomposition tree. The physical organization 
(i.e., roll-out into separate volumes) is dependent upon the 
specifications contained in the management plan for that node. 


4.3 Roll-Out Concept and Template 

For a small information system or component, it is possible that 
each document of the documentation set (management plan, product 
specification, assurance specification, or management control and 
status reports) can be written as a single physical document. 
However, many information systems and components require that 
multiple volumes be used for each document. In the case where a 
documentation set document for an information system or component 
requires more than one volume, the concept of "roll-out" is 
employed . 

The roll-out concept provides a mechanism whereby sections of the 
document are packaged as separate volumes. The parent document 
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or volume contains pointers to each of the rolled-out sections. 
The rolled-out volume contains a pointer back to its parent. 

This preserves the overall integrity of the documentation set 
structure while offering the convenience of separately preparing 
a section of the document . The decision on which sections of the 
document are rolled-out is stated in the management plan by the 
appropriate manager as identified in Section 4.2. 

A DID is provided to describe the content of the Management 
Control and Status Reports Template (SMAP-DID-R999) . The 
standard template (Figure 4-2) is used as part of the roll-out 
mechanism. 

Because the rolled-out volume represents a single section in its 
parent document or volume, sections 3.0 through N.O of the 
rolled-out volume are actually the major subheadings for the 
section in the parent document or volume. 


MANAGEMENT CONTROL AND STATUS REPORTS TEMPLATE 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose & Objectives of Volume 

1.4 Volume Status & Schedule 

1.5 Volume Organization & Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 

3.0 thru N.O SECTIONS OF THE PARENT BEING ROLLED-OUT 

INTO A SEPARATE VOLUME 

N+1.0 ABBREVIATIONS AND ACRONYMS 

N+2 . 0 GLOSSARY 

N+3 . 0 NOTES 

N+4 . 0 APPENDICES 


Figure 4-2. Management Control and Status Reports Template. 
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The Abbreviations and Acronyms section defines all acronyms and 
abbreviations used within the document or volume. The Glossary 
section includes definitions of special terms used within the 
document or volume. 

The Notes section is used for supplemental information that is 
not part of the formal, binding information presented elsewhere 
in the document or volume. 

Appendices are considered to be an integral part of the document 
or volume. They may be separately page numbered, or included in 
the pagination for the volume as a whole. They may bear a 
section number within the overall volume, or may be separately 
identified. 


4.4 The Management Control and Status Reports Document Standard 
and Rules 

All of the standards contained in the parent document 
(Information System Life-Cycle and Documentation Standards) shall 
apply to management control and status reports documents. This 
section contains additional rules that are specific to 
documentation . 

For the information system itself, and for each subordinate 
information system (subsystem) and software, hardware, and 
operational procedures component identified in the decomposition 
tree, the following standards shall apply: 

1) There shall be a single management control and status 
reports document consisting of one or more volumes. This 
document shall be prepared as specified by the DIDs given 
Section 7 . 

2) The acquirer manager shall be responsible for the management 
control and status reports document, and its roll-out into 
separate volumes. All reports identified in the management 
plan shall be identified and referenced in the management 
control and status reports document. 

3) The following rules shall be applied when generating a 
management control and status reports document or volume 
and the associated reports: 

a) The roll-out of a section into a separate volume shall 
follow the standard format specified by the Management 
Control and Status Reports Template DID ( SMAP-DI D-R9 99) 
given in Section 7. 

b) The minimum content of any management control and status 
reports volume shall be a list of report types and their 
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traceability to a specific section of the management 
plan and to the document they affect or apply to. For 
each report type, there shall be an index (or a pointer 
to an online index) and an identification of the reports' 
location. 

c) Each rolled-out volume shall be titled as illustrated 
below. This method supports the standard and enables 
one to place the volume in context with its parent (s) . 

< title of the rolled-out section > 

Volume of the 
[ < parent volume title > 

Volume of the ] 

< documentation set parent title > 

Document 

Note that the volume entry in brackets ( [ ] ) above is to 
be expanded zero or more times depending on the number 
of levels of roll-out from the documentation set parent. 
Additional information may be included on the title page 
as specified by delivery requirements. 

d) When writing the management control and status reports 
document, the outline specified by the Management Control 
and Status Reports DID shall be used. If more detailed 
structuring is needed for a section than that shown in 
this DID, then detail may be added at the discretion of 
the author. The form and content of additional sub- 
sections shall conform to the DID. 

e) A section shall either: 
o contain information; 

o point to a lower level volume rolled-out from this 
document or volume; 

o point to another document (e.g., the contract 

governing the effort) that contains the information 
appropriate to the section; 

o be marked TBD (to be determined) if appropriate 
information is not yet available; or 

o be marked "Not applicable" or "None." 

If a section is "Not applicable" or "None," then none of 
its subordinate sections shall appear. 

f) The documentation standard designates a unique place for 
each element of information. The same information shall 
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not be incorporated in more than one place when gen- 
erating a document or rolled-out volume. 

g) Reports shall contain, at a minimum, the information 
defined in the content description for that report in the 
Management Control and Status Reports DID. Additional 
reports (other than those identified in Section 7) may be 
specified in the management plan; their content is the 
responsibility of the appropriate manager. 

h) Any document . that is to be placed under any level of 
an organization's configuration management shall be 
compatible with the appropriate electronic formats 
specified in applicable support environment (s) (such as 
the SSE and TMIS documentation formats for the Space 
Station Freedom Program. ) 
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5.0 APPLICATION AND SUPPORT OF MANAGEMENT CONTROL AND STATUS 
REPORTS DOCUMENTATION STANDARD 

This section provides guidelines for tailoring and using this 
standard to prepare a Management Control and Status Reports 
document or volume thereof. 


5.1 Guidelines 

The following collection of guidelines is offered to assist in 
applying this standard. 


5.1.1 How to Use the DIDs to Prepare a Management Control and 
Status Reports Document 

Start with the Management Control and Status Reports DID 
( SMAP-DI D-RO 00) . Based upon the reports identified in the 
management plan, group all report types by responsible 
organization and classification (management, engineering, or 
assurance) . The classification refers to the document affected 
by a particular report type (management plan, product 
specification, or assurance specification) or to which document 
the report type applies. 

For each report type, document the indexing, storage, and 
retrieval mechanism. 

Sections for which no reports exist should be marked "Not 
applicable" . 

If individual reports are included in the Management Control and 
Status Reports document, (as opposed to being contained in a 
repository) , then subsection structure should be added for that 
report type. If the reports are not contained in this document, 
then the document contains an index (or pointer to an index) and 
an identification of the location of the reports. 

The roll-out structure for the Management Control and Status 
Reports document should, in general, mirror the roll-out 
structure for the management plan. 


5.1.2 Use of a Standards and Procedures Repository 

Acquirer and provider managers are responsible for determining 
the need and establishing a repository for any additional 
procedures, guidelines, rules, and practices for documentation 
that are not already defined in an existing repository, (such as 
the ones maintained for the Space Station Freedom Program by TMIS 
and the SSE) , or a parent information system or component 
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repository. At the manager's discretion, procedural information 
for minor or unique matters may be included as added subsections 
in a documentation set document (per rule for additional 
sections) . 


5.2 Tools Supporting the Application and Use of the 
Documentation Standard 

Support environments may provide tools for the application and 
use of the documentation standard. For example, TMIS and the SSE 
provide tools for the Space Station Freedom Program that support 
the documentation standards. Such tools are used when preparing, 
reviewing, revising, publishing, distributing, and configuration 
managing documents. Tools are also provided for preparing a WBS 
and schedules. Tool support of the standards is the 
responsibility of the program/project. 
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6.0 ASSURANCE AND ENFORCEMENT OF THE DOCUMENTATION STANDARD 

If the SMAP information system life-cycle and documentation 
standards have been selected as standards by program/project 
management , then it is the responsibility of the acquiring 
manager of the information system or component to assure and 
enforce this documentation standard for all documentation written 
for that information system or component. 

The assurance process is formally addressed in one of two ways: 

1) As a quality assurance activity during the phase transition 
reviews indicated by the information system life-cycle. 

2) As explicitly called for within any planning document. 

(For example, an assurance plan section of the management 
plan could call for special reviews of individual documents 
and volumes . ) 

The information system life-cycle specifies that the management 
control and status reports document be prepared initially m 
conjunction with the management plan during the concept and 
initiation life-cycle phase. This version of the management 
control and status reports document is reviewed at the end of the 
concept and initiation phase. The schedule for preparation, 
submission, and approval of the reports themselves shall be 
specified in the management plan. The review of the reports as 
they are generated and their insertion into the management 
control and status reports document are part of the 
program/project's assurance activities for each ^ phase . of the 
life-cycle. The plan for these assurance activities is defined 
in ass ur ance planning sections of the management plan. 

It is the responsibility of the reviewers of management control 
and status reports document to be familiar with this 
documentation standard and to question any deviations from this 
standard . 

Because all sections specified in a DID must be included in the 
document or volume, managers and participants in management 
reviews can easily verify that all necessary information has been 
prepared. The structure for the document serves as a gross level 
checklist. 
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7.0 DATA ITEM DESCRIPTIONS (DIDS) 

This section contains the specifications for the format, outline, 
and content of the management control and status reports document 
and template. The minimum content for report types designated in 
the document is identified, but the exact format and content for 
the reports themselves must be specified in the management plan. 

The Management Control and Status Reports Template 
(SMAP-DID-R999) , provides detailed instructions for preparing the 
sections that are common to all management control and status 
reports documents or volumes. Note that this DID does not 
represent a particular separate document or volume but is used to 
generate a volume format for a section that a manager wishes to 
document in a separate volume. 

The Management Control and Status Report DID (SMAP-DID-R000) 
provides an outline for the complete management control and 
status reports document for an information system or a software, 
hardware, or operational procedures component. Any section or 
subsection of this DID may be rolled-out into a separate volume. 

For your convenience, the list of DIDs from the Table of Contents 
is repeated below. 

Management Control and Status Reports Document 

DID SMAP-DID-R000 !' 

Management Control and Status Reports Template 

DID SMAP-DI D-R9 9 9 2S 

Minimum Content for Reports 2" 


LIST OF REPORTS FOR WHICH MINIMUM CONTENTS ARE SPECIFIED 


The following pages specify the minimum content for management 
control and status reports: 


CERTIFICATION REPORT 

CONFIGURATION AUDIT REPORT 

CUSTOMER INSPECTION REPORT 

DISCREPANCY (NRCA) REPORT 

ENGINEERING CHANGE PROPOSAL . . . 

LESSONS LEARNED REPORT 

PERFORMANCE/STATUS REPORTS 

REVIEW REPORT 

TEST REPORT 

WAIVER/ DEVIATION REQUEST 


SMAP-DID-R001 27 

SMAP-DI D-RO 0 2 28 

SMAP-DID-R003 29 

SMAP-DID-R004 30 

SMAP-DID-R005 31 

SMAP-DI D-RO 0 6 32 

SMAP-DID-R007 33 

SMAP-DID-R008 34 

SMAP-DID-R009 35 

SMAP-DID-R010 36 


Additional reports may be required for a particular application. 
The content and format of these reports are specified in the 
management plan. 
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SMAP-DID-ROOO 

MANAGEMENT CONTROL AND STATUS REPORTS DOCUMENT 
DATA ITEM DESCRIPTION 

TABLE OF CONTENTS 

Section 

1 . 0 INTRODUCTION 

2 . 0 RELATED DOCUMENTATION 

3 . 0 ACQUIRER ' S REPORTS 

4.0 DEVELOPMENT PROVIDER'S REPORTS 

5.0 SUSTAINING ENGINEERING AND OPERATIONS 

PROVIDER'S REPORTS 

6.0 ABBREVIATIONS AND ACRONYMS 

7 . 0 GLOSSARY 

8 . 0 NOTES 

9 . 0 APPENDICES 
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EXPLANATORY NOTE 

The purpose of the management control and status reports 
document is to provide a "logical" home for all reports 
that are specified in the management plan and generated 
throughout the life-cycle for a specific information system 
or component. This document provides a mechanism for 
storing and retrieving each individual report. 


1.0 INTRODUCTION 

The structure and content description to be used when preparing 
this section is described in detail in the Management Control and 
Status Reports Template DID (SMAP-DID-R999) . 


2 . 0 RELATED DOCUMENTATION 

The structure and content description to be used when preparing 
this section is described in detail in the Management Control and 
Status Reports Template DID (SMAP-DID-R999) . 


3.0 ACQUIRER'S REPORTS 

The purpose of this section is to provide a "logical home" for 
(or master index to) all reports under the responsibility of the 
acquirer as specified in the acquisition plan section of the 
management plan. The actual mechanism to control and store all 
the reports is determined by the acquirer. For example, the 
reports may be physically placed in this document, or this 
document may contain only a description of each report type and 
index and location information for the actual reports for each 
report type. 

This section is organized by applicability classification of the 
report type: 

o Management reports to the acquisition plan section of the 
Management Plan 

o Assurance reports to the acquirer's section of the 
Assurance Specification 

o If applicable, engineering reports to the Product 
Specification 

Under each applicability subsection, for each report type, the 
following information should be provided: 
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1) Report title. 

2) Section of the management plan that specifies this 
report is to be generated. 

3) Index of reports that have been generated (or pointer 
to an online index of same) . 

4) Actual reports (or identification of where reports are 
stored) . 

If there is an organizational partitioning of responsibilities 
within the acquirer's organization (such as, an independent 
verification and validation provider) , then the reports may first 
be grouped by organizational responsibility and then by 
management, assurance, and engineering type. 


4.0 DEVELOPMENT PROVIDER'S REPORTS 

The purpose of this section is to provide a "logical home" for 
(or master index to) all reports under the responsibility of the 
developer as specified in the development plan section of the 
management plan. The actual mechanism to control and store all 
the reports is determined by the developer. For example, the 
reports may be physically placed in this document or this 
document may contain only a description of each report type and 
index and location information for the actual reports for each 
report type. 

This section is organized by applicability classification of the 
report type: 

o Management reports to the development plan section of 
the Management Plan 

o Assurance reports to the developer's section of the 
Assurance Specification 

o Engineering reports to the Product Specification 

Under each applicability subsection, for each report type, the 
following information should be provided: 

1) Report title. 

2) Section of the management plan that specifies this 
report is to be generated. 

3) Index of reports that have been generated (or pointer 
to an online index of same) . 
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4) Actual reports (or identification of where reports are 
stored) . 


If there is an organizational partitioning of responsibilities 
within the developer’s organization (such as, an independent 
configuration management organization) , then the reports may 
first be grouped by organizational responsibility and then by 
management, assurance, and engineering type. 


5.0 SUSTAINING ENGINEERING AND OPERATIONS PROVIDER'S REPORTS 

The purpose of this section is to provide a "logical home" for 
(or master index to) all reports under the responsibility of the 
sustaining engineering provider as specified in the sustaining 
engineering and operations plan section of the management plan. 
The actual mechanism to control and store all the reports is 
determined by the sustaining engineering provider. For example 
the reports may be physically placed in this document or this ' 
document may contain only a description of each report type and 
index and location information for the actual reports for each 
report type. 

This section is organized by applicability classification of the 
report type : 

o Management reports to the sustaining engineering and 
operations section of the Management Plan 

o Assurance reports to the Assurance Specification 

o Engineering reports to the Product Specification 

Under each applicability subsection, for each report type, the 
following information should be provided: 

1) Report title. 

2) Section of the management plan that specifies this 
report is to be generated. 

3) Index of reports that have been generated (or pointer 
to an online index of same) . 

4) Actual reports (or identification of where reports are 
stored) . 


If there is an organizational partitioning of responsibilities 
within the provider's organization, then the reports may first be 
grouped by organizational responsibility and then by management, 
assurance, and engineering type. 
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6.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Management Control and Status Reports Template DID 
(SMAP-DID-R999) for the detailed description of content for this 
section. 


7 . 0 GLOSSARY 

Refer to the Management Control and Status Reports Template DID 
(SMAP-DID-R999) for the detailed description of content for this 
section. 


8 . 0 NOTES 

Refer to the Management Control and Status Reports Template DID 
(SMAP-DID-R999) for the detailed description of content for this 
section. 


9 . 0 APPENDICES 

Refer to the Management Control and Status Reports Template DID 
(SMAP-DID-R999) for the specifications for appendices. 
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SMAP-DI D-R9 9 9 

MANAGEMENT CONTROL AND STATUS REPORTS TEMPLATE 
DATA ITEM DESCRIPTION 


TABLE OF CONTENTS 


Section 


1 . 0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 

3.0 - N.O [Major subsections of the Management Control and 
Status Reports being rolled-out into a separate 
volume] 

N+1.0 ABBREVIATIONS AND ACRONYMS 

N+2 . 0 GLOSSARY 

N+3 . 0 NOTES 

N+4.0 APPENDICES 
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EXPLANATORY NOTE 

The purpose of the template is to describe the set of 
common sections that are to appear in the document 
specified by this documentation standard and in any 
rolled-out volumes. When using this template for the 
document itself, rather than for a rolled-out volume, 
substitute "Document" for "Volume" in the following. 


1 . 0 INTRODUCTION 


1.1 identification of Volume 

Identify this physical volume in terms of its relationship to the 
parent document (s) in the documentation set for this information 
system or component. For documentation set documents, identify 
the parent (s) in the decomposition tree for the information 
system. For example: 

"This is the Management Control and Status Reports Document 
for the XYZ Information System." 

"This is the Engineering Change Proposals Volume of the 
Technical Reports Volume of the XYZ Information System 
Management Control and Status Reports Document." 


1.2 Scope of Volume 

Describe the area of cognizance, responsibility, and 
applicability for this volume. 

1.3 Purpose and Objectives of Volume 

Describe the purpose and objectives for this volume concisely and 
in specific terms. 


1.4 Volume Status and Schedule 

Describe the status, including goals and dates, for production or 
revision of the volume. Documentation is often generated 
incrementally or iteratively. If this is the case for this 
volume, also summarize here the planned updates and their release 
dates . 


Release 4.3, 2/28/89 


23 



MANAG EME NT CONTROL AND STATUS REPORTS STANDARD 
MANAGEMENT CONTROL AND STATUS REPORTS TEMPLATE: SMAP-DID-R999 


1.5 Volume Organization and Roll-Out 


Briefly describe what is presented 
this version of the volume and what 


in each major section within 
is in each appendix. 


if an Y sections are rolled-out into subordinate volumes of this 
then cite those volumes and provide a documentation tree 
pointing to the subordinate volumes and relating them to the 
parent . 


2 . 0 RELATED DOCUMENTATION 


The purpose of this section is to provide the references or 
bibliography for this volume. 


Cite documents by short or common 
version or release designator (if 
or source, and document number or 


title (if any), full title, 
appropriate) , date, publisher 
other unique identifier. 


2 . 1 Parent Documents 


Begin this section as follows, depending upon whether this is a 
volume of a document or the document itself: 

The following document(s) is (are) parent to this volume:" 
or: 

document (s) is (are) the parent from which this 
document's scope and content derive:" 

? document, cite the appropriate document at the next 

^f Ve iu For example ' an Information System Management Plan 
would cite the management plan for the next higher level 
information system, or the Software Product Specification would 
cite the Software Management Plan and the parent's product 
specification. If there is no higher level, state "None." here. 

If this is a volume rolled-out from a document, cite that 
document. If this is a volume rolled-out from another volume, 
cite each volume in the hierarchical path back to the parent 

document, starting with the volume immediately superior to this 
one . 
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2.2 Applicable Documents 

Begin this section as follows: 

"The following documents are referenced herein and are 
directly applicable to this volume:" 

Provide the citations for every document (other than the parent) 
referenced within this volume, or which are directly applicable, 
or contain policies or other directive matters that are binding 
upon the content of this volume. 


2 . 3 Information Documents 

Begin this section as follows: 

"The following documents, although not directly applicable, 
amplify or clarify the information presented in this 
volume, and are not binding:" 

or, use an appropriate introduction to indicate the relationship 
of the documents listed here to this volume. 


3.0 - N.O CONTENT FOR ROLLED-OUT SECTION 

Each major section or subsection of an information system or 
component management control and status reports document, or of a 
volume thereof, being rolled-out into a separate subordinate 
volume becomes a major section in the rolled-out volume. 


N+1.0 ABBREVIATIONS AND ACRONYMS 

This section follows the sections containing the content for the 
rolled-out section. 

The abbreviations and acronyms section contains an alphabetized 
list of the definitions for abbreviations and acronyms used in 
this volume. 


N+2 . 0 GLOSSARY 

The glossary contains an alphabetized list of definitions for 
special terms used in the volume ; i . e . , terms used in a sense 
that differs from or is more specific than the common usage for 
such terms. 
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N+3 . 0 NOTES 

Use this section to present information that aids in 
understanding the information provided in previous sections, and 
which is not contractually binding. 


N+4 . 0 APPENDICES 

The appendices contain material that is too bulky, detailed, or 
sensitive to be placed in the main body of text. Refer to each 
appendix in the main body of the text where the information 
applies. Appendices may be bound separately, but are considered 
to be part of the volume and shall be placed under configuration 
control as such. 
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MINIMUM CONTENTS FOR CERTIFICATION REPORT 


EXPLANATORY NOTE 

The purpose of the report is to present to management a 
summary of certification activity results for a product or 
group of products. The requirements both for the specific 
certification activity and for associated reports and the 
frequency of their generation are specified in the 
management plan. The description of the supporting test(s) 
(test specifications, test data, test results, etc.) and 
other assurance activities is given in the assurance 
specification. The description of the product being 
certified is given in the product specification. 

The information listed below is considered to be the 
minimum content for a certification report. The specific 
content and format for this report is specified in the 
management plan. 


Topics to be included in the certification report are: 

o Identity of the certification activity as defined in the 
assurance specification 

o Version identification of product under certification as 
defined in the product specification plus any environment 
definition 

o Date of certification activity 
o Certification team members (if appropriate) 
o Certification witnesses (if appropriate) 
o Agency granting certification 

o Status of certification activity 

- status of activity 

- certification criteria unfulfilled 

- limitations restricting or precluding certification 
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MINIMUM CONTENTS FOR CONFIGURATION AUDIT REPORT 


EXPLANATORY NOTE 

The purpose of the report is to provide status on a 
configuration audit activity to management. The 
requirement both for the configuration audit activity and 
for associated reports and the frequency of their 
generation are specified in the management plan. The 
description of a configuration audit activity is cfiven in 
the assurance specification. A configuration audit may 
apply to either a product or a process. This minimum 
content statement applies, therefore, to physical 
configuration audits and configuration management 
configuration audits. The information listed below is 
considered to be the minimum content for a configuration 
audit report. The specific content and format for this 
report is specified in the management plan. 


Topics to be included in the configuration audit report are: 

o Identity of the configuration audit as defined in the 
assurance specification 

o Version identification of product or process under config- 
uration audit and any environment identification 

o Date of configuration audit 

o Audit team members (if appropriate) 

o Anomalous conditions encountered and recommendations made 
o Configuration audit summary and status 
o Date of follow-up audit 
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MINIMUM CONTENTS FOR CUSTOMER INSPECTION REPORT 


EXPLANATORY NOTE 

The purpose of the report is to provide the status of a 
customer inspection to management. The requirement both 
for the inspection activity and for associated reports and 
the frequency of their generation are specified in the 
management plan. The description of the inspection 
criteria, etc. , is given in the assurance specification. 

The description of the product being inspected is given in 
the product specification. The information listed below is 
considered to be the minimum content for a customer 
inspection report. The specific content and format for 
this report is specified in the management plan. 


Topics to be included in the customer inspection report are: 

o Identity of the customer inspection as defined in the assur- 
ance specification 

o Version identification of the product under customer in- 
spection as defined in the product specification plus 
environment identification 

o Date of customer inspection 

o Inspection team members (if appropriate) 

o Inspection status and summary of results 
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MINIMUM CONTENTS FOR DISCREPANCY (NRCA) REPORT 
EXPLANATORY NOTE 

The purpose of the report is to state a discrepancy to a 
product or product specification. The process of filing a 
report of this type may be referred to as nonconformance 
reporting and corrective action (NRCA) . A nonconformance 
is defined as any deviation of a product or process from 
applicable requirements, standards, or procedures. The 
requirement for reports of this type and the process for 
analysis and disposition is specified in the management 
plan. The information listed below is considered to be the 
minimum content for a Discrepancy (NRCA) report. 

Topics to be included in the Discrepancy (NRCA) report are: 

o Report identification (Discrepancy Report or NRCA number) 

o Originator identification including 

- name and organization 

- address and phone 

- unit or site of occurrence 

o Product identification including 

- name 

- version number (plus release date if applicable) 

- if applicable, environment information (e.g. , hardware 
and operating system for a software product) 

" life-cycle phase in which nonconformance detected 

o Discrepancy Report (NRCA) information including 

- title 

- date 

- type of nonconformance 

- description 

- recommendation for proposed solution (if any) , including 
code, data, or documentation where corrective action 
must be taken 

o Approval authority including 

- criticality 

- disposition 

- resolution 

- implementation schedule 

- date/version of the item in which the corrective action 
will be included 

- authority signature 

- date tested 

- date of closure 
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MINIMUM CONTENTS FOR ENGINEERING CHANGE PROPOSAL (ECP) 


EXPLANATORY NOTE 

The purpose of the engineering change proposal is to state 
a suggested change to a product. The requirement for use 
of engineering chancre proposals and the process for their 
analysis and disposition is specified in the management 
plan. The information listed below is considered to be the 
minimum content for an engineering change proposal. The 
specific format for the engineering change proposal report 
to be used for an information system or component is 
specified in the management plan. 

Topics to be included in the engineering change proposal are: 

o Proposal identification 

o Originator identification including 

- name and organization 

- address and phone 

o Product (including documents) identification including 

- name or title 

- yersion number (plus release date if applicable) 

- if applicable, environment information (e.g. , hardware 
and operating system for a software product) 

o Proposal information including 

- title 

- date 

- classification (i.e, major or minor) 

- priority 

- description of proposed change 

- recommendation (if any) 

o Proposal analysis including 

- classification 

- resources required to implement change 

- effect upon operational personnel and training 

- suggested resolution 

- reference to associated analysis 

o Change authority including 

- disposition 

- resolution 

- implementation schedule 

- authority signature 
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MINIMUM CONTENTS FOR LESSONS LEARNED REPORT 


EXPLANATORY NOTE 

The purpose of this report is to record, for the purpose of 
improvement in future applications, the major strengths and 
weaknesses of the management, engineering, and assurance 
process for an application, and the resultant product. 

This is not an evaluation of the current application. 
Rather, it is a distillation of the experience gained that 
will be useful when applied to similar activities in the 
future . 


Topics to be included in the lessons learned report are lessons 
learned on matters such as: 

o Author or submitter 

o Identification of information system or component 

o Unique approaches for methods, practices and standards 

o Useful management planning and control techniques 

o Major problem areas and how resolved; identify problems 
unresolved 

o Successful aspects and shortcomings of the planning, 
development, and assurance process 

o Recommendation for future applications 
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MINIMUM CONTENTS FOR PERFORMANCE/STATUS REPORTS 


EXPLANATORY NOTE 

The purpose of this report is to inform management about 
the performance or status of a process or product. The 
requirement for reports of this type and their frequency 
are specified in the management plan. The information 
listed below is considered the minimum content for a 
performance or status report. The specific content and 
format is specified in the management plan. 


Topics to be included in performance/ status reports are: 

o Identification of activity or process to which this report 
relates 

o Author or submitter 
o Accomplishments 

o Significant variances in planned versus actual performance 
o Open items or problems 
o Recommendations for corrective action. 
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MINIMUM CONTENTS FOR REVIEW REPORT 


EXPLANATORY NOTE 

The purpose of the review report is to record the conduct 
and status of a formal or informal review, walkthrough, 
inspection, or similar product assurance activity, as 
specified in the management plan. A description of the 
assurance activity including criteria and results is 
documented in the assurance specification. The specific 
content and format for this report is specified in the 
management plan. 


Topics to be included in a review report are: 

o Identification of the review as specified in the assurance 
specification 

o Identification of the product or process reviewed 

o Identification of the organization or person responsible 
for the product or process reviewed 

o Date and place of the review 

o List of reviewers and organizations represented 

o Summary of review results and status 

o List of actions to be taken, and by whom, as determined 
during the review 

o Approval action and authority taken as a result of the 
review 
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MINIMUM CONTENTS FOR TEST REPORT 


EXPLANATORY NOTE 

The purpose of the report is to provide the status of a 
test, or a sequence of tests, to management. The 
requirement both for the tests and for reports of this type 
and the frequency of their generation are specified in the 
management plan. The description of the test (test 
specifications, test data, test results, etc.) is given in 
the assurance specification. The description of the 
product tested is given in the product specification. The 
information listed below is considered to be the minimum 
content for a test report. The specific content and format 
for this report is specified in the management plan. 


Topics to be included in the test report are: 

® Identity of the test as defined in the assurance 
specification 

o Version identification of product under test as defined 
m the product specification 

o Date of test 

o Test team members (if appropriate) 

o Test witnesses (if appropriate) 

o Anomalous conditions encountered and recovery 
procedures attempted 

o Test status and summary of results 
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MINIMUM CONTENTS FOR WAIVER/ DEVIATION REQUEST 


EXPLANATORY NOTE 

The purpose of the request is to obtain a waiver or 
deviation from a required process or product. The 
requirexaent for requests of this type and the process for 
analysis and disposition are specified in the relevant 
management plan (or parent plan) . < The information listed 
below is considered to be the minimum content for a 
waiver/deviation request. The specific content and format 
fgf this request is specified in the management plan. 


Topics to be included in the waiver/deviation request are: 
o Waiver/deviation identification 

o Requester identification including 

- name and organization 

- address and phone 

o Product or process identification including 

- name . , . ... 

- version number (release date if applicable) 

o Waiver/deviation description 

o Rationale for acceptance of waiver/deviation 
o Schedule, cost, or other resources impact analysis 
o Safety, security, or other risk analysis 

o Change authority including 

- disposition 

- resolution 
implementation schedule 
authority signature 
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8.0 ABBREVIATIONS AND ACRONYMS 

AR - Acceptance Review 

CDR - Critical Design Review 

COTS - Commercial off-the-shelf 

DID - Data Item Description 

DoD - Department of Defense 

DRL - Data Requirements List 

ECP - Engineering Change Proposal 

EPROM - Erasable Programmable Read-Only Memory 

FCA - Functional Configuration Audit 

FMEA - Failure Modes and Effects Analysis 

GFE - Government-furnished equipment 

IV&V - Independent Verification and Validation 

LRU - Line (or Lowest) Replaceable Unit 

MTBF - Mean Time Between Failures 

MTTR - Mean Time to Repair 

NASA - National Aeronautics and Space Administration 
NHB - NASA Handbook 

NRCA - Nonconformance Reporting and Corrective Action 

PCA - Physical Configuration Audit 

PDR - Preliminary Design Review 

PROM - Programmable Read-Only Memory 

RFP - Request for Proposal 

RID - Review Item Discrepancy 

ROM - Read-Only Memory 

RR - Requirements Review 
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SMAP - Software Management and Assurance Program 
SOW - Statement of Work 

SRM&QA - Safety, Reliability, Maintainability, and Quality 
Assurance 

SSE — Software Support Environment of the Space Station Freedom 
Program 

SSFP - Space Station Freedom Program 
STD - Standard 

TBD - To be determined (at a later date) 

TMIS - Technical and Management Information System of the Space 
Station Freedom Program 

TRR - Test Readiness Review 

V&V - Verification & Validation. 

WBS - Work Breakdown Structure 
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9 . 0 GLOSSARY 

For terms not appearing in this glossary, refer to the IEEE Stan- 
dard Glossary (as referenced in Section 2.2). 


Acceptance Review - The phase transition review for the Acceptance 
and Delivery life-cycle phase. 

Acquirer - An organization that acquires a capability, such 
as an information system. 

Adaptation - The tailoring of the life-cycle and documentation 

standards (within the specifications of the rules and guide- 
lines) for a specific program/project, information system, 
or component . 

Allocation - The process of apportioning requirements at one level 
in the decomposition tree to the subsystems or subcomponents 
at the next lower level in the decomposition. 

Assembly - A physical element of a hardware component consisting 
of one or more line replaceable units. A hardware component 
is composed of one or more physical assemblies. 

Assurance - Includes any and all activities, independent of 
organization conducting the activity, that demonstrate 
the conformance of a product to a prespecified criteria 
(such as to a design or to a standard) . 

Assurance Specification - One of the four documents in the docu- 
mentation set for an information system or component; it en- 
compasses all the technical (i.e., non-planning) aspects of 
the assurance activities for an information system or compo- 
nent. 

Baselining - The official acceptance of a product or its 

placement under configuration management as defined in the 
management plan. 

Code Q - (NASA) Office of Safety, Reliability, Maintainability, 
and Quality Assurance 

Component - l) One of the three parts making up an information 
system: software, hardware, or operational procedures. 

2) A portion of a higher-level component of the same type; 
e.g., a component of the software component (of an information 
system) . 

Critical Design Review - The phase transition review for the 
Detailed Design life-cycle phase. 
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Data Item Description - The table of contents and associated 
content description of a document or volume. 

Design Element — An identifiable part of a component's archi- 
tectural design. 

Developer - The provider organization responsible for development 
of an information system or of a hardware, software, or 
operational procedures component. 

Document - One of the four basic types of information for each 
information system or component: 1) Management Plan, 

2) Product Specification, 3) Assurance Specification, and 
4) Management Control and Status Reports Document. A 
document consists of one or more volumes. 

Documentation Set - The four basic documents for each information 
system or component thereof. 

Evolutionary Acquisition - The acquisition of an information system 
over a relatively long period of time in which two or 
more complete iterations of the life-cycle will be employed 
to revise and extend the system to such an extent as to 
require a major requirements analysis and therefore subse- 
quent life-cycle iterations. 

Increment - A pre-defined set of units integrated for integration 
testing by the development organization in response to incre- 
mental development plans. 

Incremental Development - The process of developing a product 
before delivery in a series of segments. These segments 
remain internal to the development organization. The process 
is used to avoid the big bang approach to software development 
and help minimize risk. The segments are defined based on 
the design and documented in the design section of the product 
specification. The process leads to a single delivery unless 
used in conjunction with "phased delivery." 

Independent Verification and Validation - Verification and 

validation performed by an independent organization. In 
general, this is intended to be independent of the develop- 
ment organization. For complete independence, the IV&V 
organization must report directly to or be funded directly 
by the acquirer. 

Information System - 1) Any system composed of hardware, soft- 
ware, and operational procedures components required to 
process , store , and/ or transmit data . 2 ) An integrated 
combination of software, hardware, and operational pro- 
cedures components that provides a useful capability. An 
information system is generally software- intensive. 
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Inheri tables - Existing software or hardware to be drawn upon in 
developing a new information system. The inheritables may 
be modified to meet the new system's requirements. 


Instantiate - 1. To represent an abstraction by a concrete 
instance (e.g., heroes instantiate ideals). 2. Within 
Ada, the process of creating an instance of a generic 
subprogram or package. 


Line Replaceable Unit - A hardware unit that is part of an assem- 
b u j at ls defined to be the lowest replaceable element of 
a ar< * ware component . An assembly is composed of one or more 

JjKUS • 


Management Control and Status Reports Document - One of the 

documents in the documentation set for an information system 
or component; it represents a "logical" home for all report 
and request forms. 


Management Plan - One of the four documentation set documents; 
it encompasses all planning information for an information 
system or component, including management, engineering, and 
assurance planning. 


Partitioning - The process of determining the content for each 
delivery when using the phased delivery approach, or for 
determining the content of each segment when using incre- 
mental development. 


Phase (of a life-cycle) - A set of activities and associated 

products and reviews that make up one step of a multi-step 
process for developing systems and their component. An 
information system life-cycle has seven standard phases: 

1) Concept and Initiation; 2) Requirements; 3) Design; 

4) Implementation Coordination (or Implementation or 
^ abr ^^ :a ^' lon ) » 5) Integration and Test; 6) Acceptance Test; 
and 7) Sustaining Engineering and Operations. In some cases 
phase 3 contains multiple levels of design, such as archi- 
tectural and detailed. 


Phase Transition Review - The review at the end of a phase trig- 
gering transition to the next phase. 

Phased Delivery - The process of developing and delivering a 

product in stages, each providing an increasing capability 
for an information system or component. The process may be 
employed to provide an early operational capability to users, 
for budgetary reasons, or because of risk, size, or complex- 
ity. Each delivery must undergo acceptance testing prior to 
release for operational use. The capabilities provided in 
each delivery are determined by prioritizing and partitioning 
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the requirements. This must be documented in the require- 
ments section of the product specification. 

Preliminary Design Review — The phase transition review for the 
Architectural Design life-cycle phase. 

Product Specification - One of the four documentation set 

documents for an information system or component ; _ it encom- 
passes all the engineering and technical support information 
related to the development of an information system or 
component . 

Prototyping - A process used to explore alternatives and minimize 
risks. Prototyping can be used in any life— cycle phase. 

The product of the process is a report. By-products (such 
as software, hardware, and models) of the process can be 
preserved for subsequent use. 

Provider - An organization providing a capability to an acquirer; 
e.g., the developer or an organization providing independent 
verification and validation. 

Quality Assurance - A subset of the total assurance activities 
generally focused on conformance to standards and plans. 

In general, these assurance activities are conducted by 
the SRM&QA organization. 

Quality Engineering - The process of incorporating reliability, 
maintainability, and other quality factors into system, 
hardware, software, and operational procedures products. 

Repository — A collection of standards, procedures, guides, 

practices, rules, etc. that supplements information con- 
tained in the documentation set for an information system 
or component. In general, the documentation set describes 
"what" is to be done and the repository provides the "how- 
to" instructions. A repository usually contains information 
that is applicable to multiple information systems and com- 
ponents . 

Requirements Allocation — The process of distributing requirements 
of an information system or component to subordinate in- 
formation systems (subsystems) or components. 

Requirements Partitioning - The process of distributing require- 
ments of an information system or component to different 
deliveries in support of phased delivery. 

Requirements Review - The phase transition review for the Require- 
ments life-cycle phase. 
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Review Item Discrepancy - A type of discrepancy report used when 
reviewing documentation. 

Risk - The combined effect of the likelihood of an unfavorable 
occurrence and the potential impact of that occurrence. 

Risk Management - The process of assessing potential risks and 
reducing those risks within dollar, schedule, and other 
constraints . 

Roll-out - A mechanism for recording sections of a document in 
physically separate volumes while maintaining traceability 
and links. Wien using roll-out, a volume is subordinate 
to a parent document or volume. 

Software Management and Assurance Program - Sponsored by NASA 
Code Q to foster more effective and productive software 
engineering methodologies . 

Subsystem - In the information system decomposition context, a 
subsystem is an information system that is subordinate to 
a higher level information system and is parent to soft- 
ware, hardware, and operational procedures components, or to 
other (lower level) information systems. 

Template - Within these Standards, a template is a DID frame- 
work used in the roll-out process for defining the specific 
format of a section rolled-out into a physically separate 
volume. 

Test Readiness Review - The phase transition review for the 
Integration and Testing life-cycle phase. 

Testing - The process of exercising or evaluating an information 
system or component by manual or automated means to demon- 
strate that it satisfies specified requirements or to iden- 
tify differences between expected and actual results. 

Tool - A hardware device or computer program used to help develop, 
test, analyze, or maintain another device or computer program 
or its documentation. (IEEE Std 729-1983) 

Unit - An identifiable part of a detailed design. A level of 
decomposition for the purpose of physical design and im- 
plementation for a software or hardware component. 

Validation - 1) Assurance activities conducted to determine that 

the requirements for a product are correct; i.e. to build the 
right product. 2) (IEEE Std 729-1983) The process of evalu- 
ating software at the end of the software development process 
to ensure compliance with software requirements. 
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Verification - 1) Assurance activities conducted to determine that 
a product is being built correctly in accordance with design 
and requirements specifications; l.e., to build the product 
right. 2) (IEEE Std 729-1983) "The process of determining 
whether or not the products of a given phase of ... develop- 
ment . . . fulfill the requirements established during the 
previous phase." 

Volume - A physically separate section of one of the four docu- 
ments In a documentation set. 


10.0 NOTES 
None. 

11.0 APPENDICES 
None. 
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